New versions of software typically contain a combination of previous release functions, new release functions and software defect fixes. New functions may be either functional or non-functional and, to any customer, each function may represent opportunity and/or risk. Where the motivation for upgrade is not for new feature consumption, many customers are concerned about the risk of an upgrade to a stable system. This concern arises from the fact that new software contains features delivered as a change to an existing, stable, operational environment. Although the enhanced functionality may help the customer justify the change to their business (and may be mandated to stay current with software maintenance agreements), the customer often seeks to assess the risk of the change to the current environment. In traditional environments, such an assessment is often based upon a “gut feel” of the stability of a system, as the decision maker generally lacks important data that would be helpful in making an objective decision. Current methods of managing this risk include testing where exhaustive regression testing is performed across the entire deployment functions. Another method is informal vendor interaction where customers ask the vendor for some understanding of the scale of changes in the released product. This is often difficult to provide, as it's generally only known by the developer themselves, who have a view of the functional change, but may not understand the potential impact of the change to an entire software system. Another approach is for the customer to wait for the first “fix-pack” before upgrading a major release. This is a common risk mitigating approach used in traditional systems with the focus being to delay upgrading unless there is a clear business need for a new feature included in a product release. A challenge of this approach, however, is that it delays the software life cycle and may provide service difficulty with the vendor when the customer is running a back-level version of the product.